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REMARKS 

This amendment is responsive to the Office Action dated April 1 1 , 2005. Applicants 
have amended claims 1-3, 13, 1 8> 23 and 24, Claims 1-25 remain pending. 

Amendments to Specification 

Per the Examiner's request, Applicants have amended the specification to update the 
status of the parent priority document. 

Per the Examiner's request, Applicants have updated the specification to capitalize the 
use of trade names. 

Applicants respectfully decline amendment to the claims to number each line as this is 
not the preferred numbering scheme of the Applicants. 

Claim Rejection Under 35 U.S.C. S 103 
Claims 2-5, 5, 18-19, 22-23 

hi the Office Action, the Examiner rejected claims 1-3, 5, 18-19, 22-23 under 35 U,S-C 
1 03 (a) as being unpatentable over Susai et al. (USPN 2002/0059428) in view of Sridhar et aL 
(USPN 6,266,701). 

Applicants respectfully traverse the rejection. The applied references fail to disclose or 
suggest the inventions defined by Applicants' claims, and provide no teaching that would have 
suggested the desirability of modification, to arrive at the claimed invention. 

With respect to claim 1, the Examiner correctly recognized that Susai fails to teach or 
suggest a network device having an HTTP multiplexor/demultiplexor that distributes requests 
over an individual server TCP connection to a corresponding socket on the server. As aptly 
stated by the Examiner, Susai "focuses on a type of multiplexing wherein the connection 
between interface unit 202 and server S is remained [sic] open for the next incoming stream [to 
service a subsequent client].'' This fact is clearly demonstrated throughout Susai and shown in 
FIG. 3 in which a new connection is always opened (step 308) unless an existing connection is 
"free" (step 306). FIG. 6 illustrates this is more detail by depicting a first client CI accessing the 
server S and then specifically issuing a close request 514 ? allowing the connection to S to be 
"free" for use by a subsequent client C2. 
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Applicants thank the Examiner for recognizing and acknowledging this fundamental 
difference between Susai and Applicants' claims. 

In rejecting claim 1, the Examiner states that Sridhar teaches Applicants* claim elements 
of multiplexing a plurality of requests together over an individual server TCP connection to a 
corresponding socket on the server. In support, the Examiner sites Sridhar at col. 6, 1L 3-15. 

Applicants respectfully submit that the Examiner has misunderstood Sridhar. Sridhar 
does not describe multiplexing a plurality of requests together over an individual server TCP 
connection to a corresponding socket on the server. In contrast, Sridhar describes techniques for 
using "alternative transport or application protocols" other than TCP or HTTP to improve 
throughput. 1 For example, Sridhar specifically states: 

[Alternative transport or application layer protocols are used, rather than the 
protocols used by the applications, on all or a portion of the communication path joining 
two applications. Features of the alternative protocols can include one or more of 
selective retransmission of lost or damaged packets, multiplexing of multiple data 
streams over a single connection, and separate rate control and flow control methods. 
These or other features of the alternative protocol can improve throughput and reduce 
latency over those achieved using the protocols such as TCP or HTTP on the entire path 
joining the applications. 
Thus, Sridhar is not referring to multiplexing TCP requests at all. Moreover, the Sridhar system 
is incapable of multiplexing TCP requests. Instead, Sridhar describes a system th at uses both 
TCP and an alternative protocol (the express transport protocol (XTP) in this case). Sridhar 
relies on the built-in rate limiting mechanisms of XTP for multiplexing and does not describe a 
system capable of providing these features. As a result, the Shridar system is unable to provide 
any of these features protocols like TCP that do not inherently support multiplexing. Sridhar 
makes this clear at col. 1 1 , 57-66, which expressly states that a different instance must be used 
for each TCP connection: 

Other transport layer protocol characteristics in the XTP segment joining gateway 
computer 612 and remote communication server 626 include explicit rate control, which 
avoids congestion along a communication path, and multiplexing of multiple logical data 
streams between computers, which provides more efficient data transfer. Note that TCP 
does not have a similar explicit mechanism for rate control, and uses a separate 
instance of the TCP protocol for each logical data stream. As described more fully 
below, each of these characteristics yields performance advantages overusing TCP. 



1 See, e.g,, Sridhar at Summary. 
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Shridar's use of XTP and TCP is perhaps even more clearly stated at col. 12, In. 25-39 as 
follows: 

Multiplexing enables one to use a single instance of the XTP protocol executing 
for a pair of computers communicating using XTP to handle multiple logical data streams 
between the two computers. This multiplexing capability is in contrast to TCP in 
which a separate instance of the TCP protocol executes independently for each 
logical data stream. An example of a, situation in which multiple data streams are 
passing concurrently between two computers is when a Web browser requests data to 
render a particular Web page. If there are embedded references to other data in a Web 
page, separate TCP data streams, each with a separate instance of the TCP protocol, 
are used to retrieve the referenced data. Using XTP, if the data is retrieved from the 
same computer, the multiple data streams are multiplexed and use only a single instance 
of the protocol. 

Thus, it is clear that Sridhar does not describe multiplexing a plurality of TCP requests together, 
or multiplexing the plurality of requests over an individual server TCP connection to a 
corresponding socket on the server. 

Instead, Sridhar must rely on features of the alternative protocol (XTP in this case) to 
achieve multiplexing/demultiplexing, and does not teach or suggest an intermediate device that 
can provide such features for TCP. Thus, Susai in view of Sridhar does not describe 
multipl exing a plurality of TCP requests together, and does not teach or suggest multiplexing the 
plurality of requests over an individual server TCP connection to a corresponding socket on the 
server. 

For these reasons, even if Susai were modified in view of Sridhar, as suggested by the 
Examiner, the resultant system would still not be able to achieve multiplexing a plurality of 
requests together over an individual server TCP connection to a corresponding socket on the 
server. None of the references teach or suggest such an ability. Instead, Sridhar goes to great 
length to teach that such junctions are not attainable and that "alternative protocols" must be 
used. Thus, neither Susai nor Sridhar, either singularly or in combination, teach or suggest an 
HTTP multiplexor/demultiplexor configured to distribute HTTP requests from a plurality of the 
clients over an individual server TCP connection to a corresponding socket on the server system, 
as required by claim 1 . This feature is not taught or suggested by any of the references. 

With respect to amended independent claim 3, for at least the reasons stated above, 
neither' Susai nor Sridhar, either singularly or in combination, teach or suggest routing HTTP 
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requests to an individual socket on a server system via a multiplexed transmission using an 
individual server TCP connection. 

Similarly, with respect to independent claim 18, for at least the reasons stated above, 
neither Susai nor Sridhar, either singularly or in combination, teach or suggest a computer 
nerworking device comprising an HTTP multiplexor/demultiplexer configured to send HTTP 
requests to a socket on the server system via a multiplexed TCP transmission. In rejecting claim 
18, the Examiner again cites Sridhar at col. 6» 11. 3-15 for such a teaching. However, as stated 
above, Sridhar is refering to use of an alternative protocol other than TCP that has built-in 
multiplexing features. 

Similarly, with respect to independent claim 22, for at least the reasons stated above, 
neither Susai nor Sridhar, either singularly or in combination, teach or suggest a computer 
networking device configured to receive HTTP requests from the clients and to distribute those 
requests via multiplexed transmission over an individual TCP connection to a server socket on 
the server system. 

With respect to claim 2, Applicants have clarified that the responses are multiplexed 
HTTP response. As correctly recognized by the Examiner, Susai fails to describe multiplexed 
communications in the manner claimed by the Applicants. Moreover, as explained above, Susai 
in view of Sridhar similarly fails to teach or suggest these elements. 

For similar reasons, with respect to claim 23, Susai in view of Sridhar similarly fails to 
teach or suggest demultiplexing responses received from a server via a multiplexed transmission. 

For at least these reasons, the Examiner has foiled to establish a prima facie case for non- 
patentability of Applicant's claims 1-3, 5, 18-19, 22-23 under 35 U.S.C. 103(a). Withdrawal of 
this rejection is requested. 

Claims 6-7, 9, 11-17, 21, 24-25 

In the Office Action, the Examiner rejected claims 6-7, 9, 1 1-1 7, 21 , 24-25 under 35 
U.S.C. 1 03(a) as being unpatentable over Susai in view of Sridhar et al. 

With respect to independent claim 6, for at least the reasons stated above, neither Susai 
nor Sridhar, either singularly or in combination, teach or suggest multiplexing the received 
requests for delivery to the server system via an individual server TCP connection. Again, the 
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Examiner correctly recognized that Susai fails to teach or suggest these elements, and Sridhar 
refers instead to selection of protocol types. With respect to TCP, Sridhar expressly states that 
separate instances of TCP must be used, which is directly contrary to Applicants* claim 6. 

Similarly, with respect to independent claim 17, for at least the reasons stated above, 
neither Susai nor Sridhar, either singularly or in combination, teach or suggest sending received 
client requests as a multiplexed transmission to the optimal server socket via an individual TCP 
connection. 

With respect to independent claim 24, for at least the reasons stated above, neither Susai 
nor Sridhar, either singularly or in combination, teach or suggest a computer networking device 
that sends each HTTP request to a determined optimal server socket via a multiplexed TCP 
transmission. 

With respect to claim 1 1 , the Examiner has apparently misquoted Sridhar, The cited 
passage does not describe determining a last-accessed server socket in order to select an optimal 
socket, as required by claim 11. To the contrary, the cited passage describes the use of a prefetch 
buffer when retrieving objects from a server so that subsequent requests can be serviced from the 
buffer, which has nothing to do with socket selection. Correction by the Examiner is requested. 

With respect to claim 12, the Examiner states that Sridhar teaches determining whether a 

server is busy, and that routing proceeds based on this limitation. However, the Examiner 

appears to again have misquoted Sridhar. Col. 23, 11. 5-10 of Sridhar states the following: 

In this approach, a gateway computer or a specially enabled client computer tries 
to make a connection to an remote communication server (which may not exist) and if 
there is no response, assume that the TCP address is not served by a remote 
communication server and, instead, proceed to establish a TCP connection. 
Thus, Sridhar is merely describing the gateway computer as determining whether a TCP address 

is serviced at all by a remote server. This is unrelated to Applicant's claim 12 where an optimal 

socket to a particular server system is selected based on unfulfilled requests for sockets to that 

server system. Contrary to the Examiner assertion, Sridhar is not determining whether a server is 

,{ busy" at all. Rather, whether a network address is usable. Moreover, whether a server is "busy" 

does not teach or suggest examining the actual number of unfulfilled requests. Correction by the 

Examiner is requested. 

With respect to claim 13, neither Susai nor Sridhar teach or suggest listening for 

multiplexed HTTP responses from the optimal, server socket via an individual TCP connection, 
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Col 15, 11 45-50 of Sridhar cited by the Examiner refers to listening to communications from the 
client , not the server. Col. 1 5, 11. 65-67 describes listening for a single response, and does not 
describe listening for multiplexed HTTP responses over the socket. Col. 20, 11. 16-30 also cited 
by the Examiner similarly refers to receiving an object from a server, and describes the use of 
XT? for communicating with the server, rather than TCP as required by Applicants' claims. 

For at least these reasons, the Examiner has failed to establish a prima facie case for non- 
patentability of Applicant's claims 6-7, 9, 11-17, 21, 24-25 under 35 U.S.C. 103(a). Withdrawal 
of this rejection is requested. 

Claims 8 and 20 

In the Office Action, the Examiner rejected claims 8 and 20 under 35 U.S.C. 1 03(a) as 
being unpatentable over Susai et al. in view of Sridhar et al. and in further view of 'Official 
Notice'. Applicants respectfully traverse the rejection for at least the reasons set forth above. 

Claims 4 and 10 

In the Office Action, the Examiner rejected claims 8 and 20 under 35 U.S.C. 103(a) as 
being unpatentable over Susai et al. in view of Sridhar et al. and in further view of Bommareddy 
(US 6,779,039). Applicants respectfully traverse the rejection for at least the reasons set forth 
above. 

For example, as set forth above with respect to claim 12, and contrary to the Examiner's 
assertion, Sridhar is not determining whether a server is "busy" at all. Rather, Sridhar is 
determining whether a network address is usable. Moreover, whether a server is "busy" does not 
teach or suggest examining the actual number of unfulfilled requests. 

Further, Bommareddy relates to controlling traffic flow across servers , not sockets . 
Contrary to the Examiner's assertion, the cited portion of Bommareddy does not describe 
selection of a socket based on a least-lengthy response time. Rather, Bommareddy suggests 
selections of different servers, which is entirely different Correction by the Examiner is 
requested. 
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Re jection for Obviousness-type Double Patenting: 

The Examiner provisionally rejected claims 1-25 under the judicially created doctrine of 
obviousness-type double patenting as being unpatentable over claims 1-26 of copending 
Application No. 09/882375. Applicants note the provisional status of this rejection. 
Accordingly, Applicants will address this issue if and when the rejection is fonnally applied. 



All claims in this application are in condition for allowance. Applicants respectfully 
request reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1 778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 



CONCLUSION 



Date: 



By: 




Name: Kent J. Sieffert 
Reg. No.: 41,312 



8425 Seasons Parkway, Suite 1 05 



St Paul, Minnesota 55125 
Telephone: 651.735.1100 
Facsimile: 651.735.1102 
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